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(57) The present invention provides methods and 
apparatus tor providing access priority in a MAC proto- 
col of a communications system such as, for example, 
with respect to UMTS RACK Particularly, the invention 
introduces several access priority methodologies in^ 
eluding: (i) random chip delay access priority (RCDAP); 
(ii) random backoff based access priority (RBBAP); (iii) 
variable logical channel based access priority (VLCAP); 
(iv) UMTS-specific variable logical channel based ac- 
cess priority (VLCAP*); (v) probability based access pri- 
ority (PBAP); and (vi) retransmission based access pri- 
ority (REBAP). Each methodology associates some pa- 
rameter or parameters to access priority classes in order 
to influence the likelihood of a remote terminal complet- 
ing a successlul access request to a base station: 
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Description 

Field of the Invention 

[0001] The present invention relates to methods and 5 
apparatus for providing access priority control in a com- 
munications system and, more particularly, to methods 
and apparatus for providing access priority control in a 
media access control protocol of a Universal Mobile Tel- 
ecommunications System. 

Background of the Invention 

[0002] A major effort has been underway in the last 
decade to integrate multimedia capabilities into mobile 
communications. The International Telecommunica- 
tions Union (ITU) and other organizations have been at- 
tempting to develop standards and recommendations 
that, ensure that mobile communications of the future 
will be able lo supporl multimedia applications with at 
least the same quality as existing fixed networks. Par- 
ticularly, many global research projects have been 
sponsored in order to develop such next (third) genera- 
tion mobile systems. Research and Development of Ad- 
vanced Communication Technologies in Europe, 
RACE-1 , and RACE-2. and Advanced Communications 
Technology and Services (ACTS) are examples of such 
efforts in Europe. It is known that in order to provide end 
users with the requisite service quality for multimedia 
communications, Internet access, video/picture trans- 
fer, high bit rate capabilities are required. Given such 
requirements, bearer capability targets for a third gen- 
eration system have been defined as 384 kilobits per 
second (kb/s) for full coverage area and 2 Megabits per 
second (Mb/s) for local area coverage. 
[0003] Universal Mobile Telecommunications System 
(UMTS) is a new radio access network based on 5 Meg- 
ahertz Wideband Code Division Multiple Access (W- 
CDMA) and optimized for support of third generation 
services including multimedia-capable mobile commu- 
nications. Since major design goals of UMTS are to pro- 
vide a broadband multimedia communications system 
that integrates infrastructure for mobile and fixed com- 
munications and to offer, inter alia, the same range of 
services as provided by the fixed and wireless commu- 
nications networks, UMTS must provide circuit- 
switched as well as packet-switched services, a variety 
of mixed-media traffic types, and bandwidthon-demand. 
However, providing multimedia support implies the need 
for flexibility, that is, being able to support services with 
different bit rates and E^Nq requirements, and to multi- 
plex such services in a multiservice environment. UMTS 
is designed to bo ab!o to support such demands. 
[0004] Referring to FIG. 1. an exemplary block dia- 
gram of a UMTS access network is shown. Particularly, 
a plurality of remote terminals 2 and 4 (e.g., mobile ter- 
minals) communicate with base stations (NODE-B) 6 via 
W-CDMA wireless links 8. The remote terminals may be 
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a variety of devices such as a wireless phone 2 or a port- 
able personal computer 4 with an internal or external 
modem. In the UMTS standard, a base station is called 
a NODE-B. These base stations communicate with a 
network component that provides radio resource man- 
agement functions and is called a Radio Network Con- 
troller (RNC). Since UMTS is a W-CDMA system, soft 
handoffs are supported. In the case of soft handoffs, 
there are two base stations 6 serving one remote termi- 
nal. Thus, the remote terminal sends frames to these 
two base stations. When the two base stations receive 
the frames from the remote terminal, they send them to 
a Frame Selector Unit (FSU). The FSU decides which 
is a better frame, in terms of frame quality, to be sent to* 
the core network. In UMTS, the FSU may be physically 
integrated with the RNC and as such, in FIG. 1 , the RNC 
and FSU are shown as block 1 0 : but also are separated 
functionally as block 1 2 (FSU) and block 1 4 (RNC). Oth- 
er elements in the UMTS network perform conventional 
functions such as: the xLR databases 20, which provide 
home and visiting location information; and the inter- 
working function (IWF) units. It is to be appreciated that 
the Universal Mobile Switching Center (UMSC) 16 
serves as the mobile switching center for the base sta- 
tions 6 in the UMTS. Sub-networks 1 8 are wireless serv- 
ice provider networks and CN1 through CNn are the 
core networks 24 to which the remote terminals are ul- 
timately coupled. 

[0005] Referring to FIG. 2, a diagram of the typical 
protocol stack in UMTS is shown. In UMTS, Layer 1 (L1 ) 
is the physical layer (PHY) which offers information 
transfer services to the MAC (Media Access Control) 
layer and higher layers. The physical layer transport 
services are described by how and with what character- 
istics data is transferred over the transport channels of 
the radio interface. Layer 2 (L2) is comprised of sublay- 
ers which include MAC, LAC (Link Access Control), and 
RLC and RLC (Radio Link Control). In UMTS, the func- 
tions performed in RLC are split and thus two RLC pro- 
tocols (RLC and RLC) are specified. The RLC and MAC 
layers provide real-time and non-real-time services. The 
MAC layer controls but does not carry out the multiplex- 
ing of data streams originating from different services. 
That is, the MAC layer, via logical channels, allows com- 
mon physical communications channels (e.g., broad- 
cast channel) to be shared by a number of remote ter- 
minals. IP (Internet Protocol) is the network layer. 
[0006] "Uu" refers lo the UMTS-spectRc interface be- 
tween a remote terminal and a base station, while "lub" 
refers to the UMTS-specific interface between a base 
station and the RNC/FSU. Layer 2 of the radio access 
network (i.e., left side of NODE-B on the protocol stack) 
is split into RLC and MAC layers, whilo Layer 2 of the 
core network (i.e., right side of NODE-B on the protocol 
stack) is more related to the technology used to trans- 
port network layer frames, e.g., ATM (Asynchronous 
Transfer Mode) or Frame Relay. IP is shown as the 
transport protocol, however, UMTS is not so limited. 
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That is, UMTS can cater to other transport protocols. 
Further details on the protocol layers may be found in 
Dahlman et al., "UMTS/I MT-2000 Based on Wideband 
CDMA, - IEEE Communications Magazine, pp. 70-80 
(September 1998) and in ETSI SMG2/UMTS L2 & L3 s 
Expert Group, "MS-UTRAN Radio Interface Protocol Ar- 
chitecture; Stage 2," Tdoc SMG2 UMTS-L23 172/98 
(September 1996). 

[0007] In UMTS, four types of application traffic need 
to be handled. They include: (i) applications that are 10 
both delay and loss sensitive, e.g., interactive video; (ii) 
applications that are loss sensitive but can tolerate mod- 
erate delay, e.g.,, interactive data; (iii) applications that 
are delay sensitive buTtolerant of moderate losses, e. 
g., voice; and (iv) applications that are tolerant of both '5 
delay and losses, e.g., tile transfer. 
[0008] To provide different Quality of Service (QoS) to 
all these different applications, the UMTS system must 
be designed appropriately. Several important issues 
need to be considered in UMTS system design such as, 20 
for example, how to satisfy QoS without wasting network 
resources and how to operate the systems in the stable 
region when all traffic types burst simultaneously. 
[0009] Further, several components are required in 
UMTS to support varying QoS. For example, service pa- 2s 
rameters need to be defined to enable different applica- 
tions to specify their different QoS requirements, e.g., 
the Guaranteed Service and Controlled Load Service 
parameters defined by the Internet Engineering Task 
Force (IETF). Users can ask for bandwidth resources 30 
either on a burst mode or connection mode. Also, there 
must be an admission control component in UMTS that 
makes decisions as to whether or not users' requests 
will be granted. The admission of new requests must be 
done such that even when all admitted requests peak 3$ 
simultaneously, the QoS requirements of each request 
will not be violated (unless they are best-effort re- 
quests). Further, once the users' requests are admitted, 
there must be features implemented in the UMTS net- 
work to deliver such service guarantees, e.g., delay re- -to 
quirement, packet loss requirement. Scheduling algo- 
rithms at the network nodes and packet marking for non- 
conformant users' traffic are some of the features that 
can be supported by routers to provide differentiated 
services. 

[0010] In order to provide end-to-end QoS in UMTS, 
certain features need to be provided at the MAC layer 
to ensure different QoS. One possible way ol providing 
different QoS is by providing priority mechanisms. Pri- 
ority mechanisms can be implemented in terms of ac- so 
cess priority, service priority or buffer management 
schemes. There are various types of service priority 
mechanisms, e.g., fixed priority, dynamic priority. Fixed 
priority mechanisms include, e.g., strict priority and 
weighted round robin. Dynamic priority schemes in- 55 
elude, e.g., fair share queuing : self-clock fair share 
queuing and worst case fair share queuing disciplines. 
[0011] With respect to access priority, several well- 



known channel access protocols are currently used in 
wireless data systems, such as Slotted Aloha, PRMA, 
etc. Conventional Slotted Aloha is a relatively simple 
protocol but, because it does not attempt to avoid or re- 
solve collisions between data users, its theoretical ca- 
pacity is just 0.37. 

[0012] Reservation-based protocols attempt to avoid 
and resolve collisions by dynamically reserving channel 
bandwidth for users needing to send packets. Typically, 
in such protocols a channel is divided into slots that are 
grouped into frames of N slots. A slot can be further sub- 
divided into k minislots. Normally, A n of the slots will be 
used for reservation purposes while the remaining A- At 
slots are dataslots. The users that need to send packets 
send a reservation request packet in one of the B=A 1 *k 
minislots. If the reservation' request packet is success- 
ful, then the user will be allocated a certain number of 
data slots until the user or the base station releases the 
reservation. If the reservation request packet is not suc- 
cessful, the user will use a conflict resolution method to 
retransmit the reservation request until it is successfully 
transmitted. 

[0013] Access priority control is particularly critical 
with respect to one of the logical channels associated 
with the media access control (MAC) protocol of UTMS, 
namely, the random access channel (RACH). RACH is 
an up-link common transport channel used to carry con- 
trol information and short user packets from a remote 
terminal. Referring to FIG. 3, a block diagram of an ex- 
emplary hardware implementation of a non-coherent 
RACH detection algorithm for use in a UMTS base sta- 
tion (NODE-B in FIG. 1) is shown. The RACH receiver 
30 is capable of providing the following functions: detec- 
tion, demodulation and decoding, and acknowledge- 
ment. The purpose of detection is to determine if a 
RACH burst, described below, is being sent by a remote 
terminal and to resolve the strongest multipath compo- 
nents of the incoming burst. The receiver 30 also de- 
modulates and decodes the message contained within 
the corresponding RACH to ascertain the remote termi- 
nal identifier and the requested service. After decoding 
a remote terminal RACH transmission, the receiver gen- 
erates an acknowledgement signal which the base sta- 
tion transmits to the remote terminal over a Forward Ac- 
cess Channel (FACH). 

[0014] The RACH receiver 30 preferably performs the 
above functions in accordance with the following struc- 
ture. A RACH transmission burst is received and de- 
modulated by mixers 32 and then filtered in filters 34. 
The signal is then sampled in sampling unit 36. De- 
spreader 38 decodes the signal in accordance with the 
spreading sequence, in this case, 512 Gold code. The 
decoded signal is buffered (buffer 40) and sent to time 
shifting unit 50. Also, the output of the despreader 38 is 
provided to integrator 42. The outputs of the integrator 
42 are mixed (mixer 44) and provided to timing detector 
46 and then threshold detector 48. The output of the 
threshold detector 48 indicates whether a valid signal 
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was received from the remote terminal. This result is 
provided to time shifting unit 50. If it is a valid signal (e. 
g., above pre-determined thresholds), the decoded sig- 
nal is then down-sampled by unit 52. Then, depending 
on the preamble, described below, the signal passes 
through the 1 6 tap filter unit 54 to the preamble signature 
searcher 56. The output of the searcher 56 provides the 
base station with the remote terminal's identifier and in- 
formation as to the service(s) requested by the remote 
terminal. 

[0015] It is known that the physical RACH is designed 
based on a Slotted ALOHA approach. A remote terminal 
can transmit a random access burst 100 at eight well- 
defined time offsets (Access slot #V, ' , Access' slot 
#i. .... Access slot #8) relative to the frame boundary of 
the received broadcast control channel (BCCH) of the 
current cell, as illustrated in FIG. 4A. As shown in FIG. 
4B, the random access burst consists of two parts, a 
preamble part 102 of length 1 millisecond (ms), a mes- 
sage part 104 of length 10 ms, and an idle lime 106 of 
length 0.25 ms in between the preamble part and the 
message part. There are a total of 1 6 different preamble 
signatures that are based on the Orthogonal Gold code 
set of length 16 (512 Gold code). The information on the 
available signatures and time offsets arc broadcast on 
BCCH. Based on this structure, if the receiver has 128 
(16 preamble signatures multiplied by 3 timeslots) par- 
allel processing units, 1 28 random access attempts can 
be simultaneously detected. In other words, we have 
equivalent 1 28 random access channels for a maximum 
configured base station for the current cell. 
[0016] Accordingly, there is a need for methods and 
apparatus for providing access priority in UMTS that ad- 
dresses the unique requirements associated with such 
a broadband multimedia communications system. Spe- 
cifically, there is a need for methods and apparatus for 
providing access priority with respect to UMTS RACH. 

Summary of the Invention 

[0017] The present invention provides methods and 
apparatus for providing access priority in a MAC proto- 
col of a communications system such as, for example, 
with respect to UMTS RACH; Particularly, the invention 
introduces several access priority methodologies in- 
cluding: (i) random chip delay access priority (RCDAP); 
(ii) random backoff based access priority (RBBAP); (iii) 
variable logical channel based access priority ( VLCAP); 
(iv) a UMTS-specific variation to the variable logical 
channel based access priority scheme (VLCAP*); (v) 
probability based access priority (PBAP); and (vi) re- 
transmission based access priority (REBAP). 
[0018] In one aspect of the invention, RCDAP meth- 
ods and apparatus are provided. In RCDAP, each prior- 
ity class is advantageously assigned a different chip de- 
lay from among chip delay distributions prior to submit- 
ting an access request to the base station. Preferably, 
those classes with a higher priority are given a smaller 



average random chip delay such that their access re- 
quests will have a higher probability of being captured 
compared to those submitted by users with a lower pri- 
ority class. - 

5 [0019] In another aspect of the invention, RBBAP 
methods and apparatus are provided. In RBBAP, each 
priority class is advantageously assigned a different 
backoff delay. Preferably, requests associated with 
higher access priority will have a smaller average back- 

io off delay. Whenever there is a collision or some other 
reason an access request is not successfully received 
at the base station, the remote terminal, depending on 
the class i, chooses a random delay distributed between 
a pre-determined range'. '~' ----- 

is [0020] In yet another aspect of the invention, VLCAP 
methods and apparatus are provided. In VLCAP, each 
subscriber is given an access priority class i. Preferably, 
those with the highest priority can access all the logical 
access channel for which the base station is configured, 

20 while those with lowest priority are only allowed to ac- 
cess a small subset of logical access channels, e.g., on- 
ly one preamble signature with 8 time offsets. A rationale 
behind this approach is that the larger the number of 
logical access channels that the remote terminal has to 

25 choose from, the higher the likelihood of finding a chan- 
nel on which the request will be successfully transmit- 
ted. 

[0021] In a further aspect of the present invention, a 
UMTS-specific variation of VLCAP methods and appa- 
30 ratus are provided. The VLCAP' approach, specifically 
takes into account a special UMTS access channel 
structure. That is, even though there are t time offsets 
for each preamble signature, there may not be t parallel 
processing units at the base station due to a limitation 
3S on the processing complexity associated with the base 
station. For example, there may only be four receivers 
with each receiver programmed to capture, for example, 
the (i th , (i+4) th ) time offsets. Thus, according to the VL- 
CAP* approach, those requests with lower priority class- 
ic es will be assigned a higher number for the time offsets, 
thus allowing the access requests from higher priority 
classes to be captured by the receivers first. 
[0022] In still a further aspect of the invention, PBAP 
methods and apparatus are provided. In PBAP, each 
•45 subscriber is given an access priority class i. Each ac- 
cess priority class i can only transmit access requests 
with a certain probability P t : Those with the highest pri- 
ority always transmit their access requests whenever 
they have an access request. 
so [0023] In yet another aspect of the invention, REBAP 
methods and apparatus are provided. In RE BAR access 
requests have an access packet priority (APP) associ- 
ated therewith whereby retransmitted access requests 
are given a higher priority over new access requests. 
£5 [0024] It is to be appreciated that access priority tech- 
niques implemented according to the present invention 
may include a combination of more than one of the 
above embodiments. For example. RCDAP can be per- 
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formed with RBBAP or VLCAP and PBAP, and so on. 
[0025] These and other objects, features and advan- 
tages of the present invention will become apparent 
from the following detailed description of illustrative em- 
bodiments thereof, which is to be read in connection with 
the accompanying drawings. 

Brief Description of the Drawings 

[0026] 

FIG. 1 is a block diagram of a UMTS access net- 
. work; ... 

FIG. 2 is a diagram of a protocol stack associated 
with a UMTS; 

FIG. 3 is a block diagram of a non-coherent RACH 
receiver for use in a UMTS; 

FIGs. 4 A and 4B illustrate access slots and a struc- 
ture of a random access burst used in a UMTS 
RACH; 

FIG. 5 is a flow chart of a method of access priority 
control at a remote terminal according to a first em- 
bodiment of the present invention; 

FIG. 6 is a flow chart of a method of acces% priority 
control at a remote terminal according to a second 
embodiment of the present invention; 

FIG. 7 is a flow chart of a method of access priority 
control at a remote terminal according to a third em- 
bodiment of the present invention; 

FIG. 8 is a flow chart of a method of access priority 
control at a remote terminal according to a fourth 
embodiment of the present invention; 

FIG. 9 is a flow chart of a method of access priority 
control at a remote terminal according to a fifth em- 
bodiment of the present invention; 

FIG. 1 0 is a flow chart of a method of access priority 
control at a remote terminal according to a sixth em- 
bodiment of the present invention; 

FIG. 11 is a flow chart of a method of access priority 
control at a base station according to the present 
invention; 

FIG 12A is a flowchart illustrating the overall 
ODMAFQ protocol operation, as viewed by the re- 
mota host; 

FIG 12B is a flowchart illustrating the overall 
ODMAFQ protocol operation, as viewed by the 



base station; 

FIG. 13A is a flowchart illustrating an embodiment 
of a method for ODMAFQ access control; 

s 

FIG. 13B is a flowchart illustrating an alternate em- 
bodiment of a method for ODMAFQ access control; 
and 

10 FIGs. 14A - 14C are flowcharts illustrating three 
ODMAFQ contention resolution methods. 

Detailed Description of Preferred Embodiments 

is [0027] The present invention is described below in the 
context of access priority control in the MAC layer of the 
UMTS, particularly, with respect to access priority con- 
trol in the random access channel or RACH. However, 
it is to be appreciated that the teachings of the invention 
20 discussed herein are not so limited. That is, the access 
priority methodologies of the invention are applicable to 
other communications systems where remote terminals 
(e.g., mobile or fixed) make random attempts to secure 
access to a communication channel associated with a 
2S base station or other communications system access 
point. In addition, it is to be understood that methodol- 
ogies described herein for use in a remote terminal or a 
base station are executed by one or more processors 
respectively associated therewith. The term "processor" 
30 as used herein is intended to . include any processing 
device, including a CPU (central processing unit) and 
associated memory. Accordingly, software instructions 
or code associated with implementing the methodolo- 
gies of the present invention may be stored in associat- 
es ed memory and, when ready to be utilized, retrieved and 
executed by an appropriate CPU. Also, the term "remote 
terminal" refers to any device capable of communica- 
tions with a base station. For example, a remote terminal 
may be mobile (e.g., wireless phone or portable person- 
40 al computer with a wireless modem) or fixed (e.g.. fixed 
personal computer with a wireless modem). Also, the 
terms 'base station" and "node_b," are used inter- 
changeably herein. 

[0028] EP-A-0912016 discloses another MAC proto- 
ns col, referred to as "on-demand multiple access fair 
queuing" or ODMAFQ. A section entitled "ODMAFQ 
MAC Protocol Operation," describing the related MAC 
functions, follows the detailed description of the present 
invention. 

so [0029] Referring back to FIG. 1 and as previously 
. mentioned, it is to be understood that the remote termi- 
nals, 2 and 4, are coupled to the UMTS access network 
through a wireless interface with base stations 6. In or- 
der to establish communications, the remote terminals 

ss send and receive media access control (MAC) frames 
over the wireless interface to and from the base stations 
6. In the case of the terminal 4, an internal or external 
modem may be used to provide a wireless connection 
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with the base stations. A remote terminal, such as re- 
mote terminal 2, typically has its own internal modem. 
Nonetheless, packets are typically generated or re- 
ceived at the remote terminal on a bursty random basis. 
The packets are buffered at the remote terminals until 
they are transmitted uplink to a base station. The base 
stations 6, as is known, provide wide-area wireless cov- 
erage and multiplex remote terminal traffic from their re- 
spective coverage area to their system's mobile switch- 
ing center, e.g., UMSC 16 in FIG. 1. The base stations 
also broadcast (down-link) packets that are destined for 
one or more of the remote terminals in its cell. 
[0030] The UMTS multiple access scheme is a time- 
slotted system (i.e., Slotted ALOHA approach) in which 
a random access channel (RACH) and a packet trans- 
mission channel are formed on a slot-by-slot basis. Time 
slot duration in each channel is chosen based on the 
particular system implemented. Generally, remote ter- 
minals that have packets to send transmit access re- 
quests via the RACH to a base station. Due to the po- 
tentially large number of remote terminals as compared 
to the relatively smaller number of access channels that 
a base station is configured to support, access priority 
schemes are necessary to ensure orderly and timely 
handling of network traffic. That is, given the fact that 
many remote terminals may randomly seek to acquire 
use of a single communications channel (i.e., they re- 
quest channel bandwidth to transfer packets), methods 
for prioritizing access requests must be implemented in 
the network in order to permit remote terminals with a 
relatively high need to access channel bandwidth asso- 
ciated with a base station over remote terminals with a 
relatively low need. So, for example, if two remote ter- 
minals have packet data to be transmitted to the base 
station, it is preferred that the access request of the re- 
mote terminal with the higher access need be more like- 
ly to be received and granted before the other remote 
terminal. However, it is to be appreciated that the priority 
class of the remote terminal is dynamic, that is, it de- 
pends on the nature and/or content of the packets to be 
transmitted and/or on the nature of the remote terminal. 
For instance, if the packets represent data that is delay 
sensitive (e.g.. interactive video, voice) or is of a nature 
that warrants immediate transmission (e.g., emergency 
situation), then the remote terminal selects a priority 
class with a priority that is commensurate with the situ- 
ation, i.e., in these cases, a high priority. Also, depend- 
ing on the service level (e.g., premium or regular) thai 
the remote terminal is subscribed to, a different access 
priority is assigned. 

[0031] Referring initially to FIG. 11, a flowchart of a 
method 1100 of access priority control at a base station 
according to the invention is shown. In UMTS, a base 
station (e.g., base station 6) broadcasts (step 1102) ac- 
cess priority system parameters in a beacon or pilot sig- 
nal to the remote terminals (RTs) in its coverage area. 
As will be particularly explained in accordance with the 
methodologies of access priority performed at a remote 



terminal, the access priority system parameters include 
parameters that the remote terminal uses in its base sta- 
tion access request process. That is. the base station 
transmits parameters pertaining to each pre-estab- 

5 lished priority class that the remote terminal receives 
and stores for use during an access request. In step 
1104, the base station (via the processor associated 
therewith) determines if an access request is received 
from a remote terminal. If not, the base station waits for 

10 one to be received. If an access request is received from 
a remote terminal, the base station transmits (step 11 06) 
an acknowledgement message to the remote terminal 
.tojndicate that the request was successfully received. 
This acknowledgement signal is transmitted on a For- 

?5 ward Access Channel (FACH) between the base station 
and the remote terminal. The base station then prepares 
for receipt of the packet data from the remote terminal 
granted access according to a packet data receipt pro- 
cedure employed in UMTS (step 1108). 

20 [0032] Referring now to FIG. 5, a flow chart of a meth- 
od 500 of access priority control at a remote terminal 
according to a first embodiment of the present invention 
is shown. It is to be appreciated that this methodology 
is performed in a remote terminal (e.g., terminal 2 or 4) 

2S which has generated or received packets to bo up-l inked 
to a UMTS base station (e.g., base station 6). The em- 
bodiment illustrated in FIG. 5 is hereinafter referred to 
as Random Chip Delay Access Priority (RCDAP). Gen- 
erally, in the RCDAP approach, each priority class isad- 

30 vantageously assigned a different average random chip 
delay prior to submitting an access request to the base 
station. Each chip is known to be a certain time duration 
and, as such, each chip represents a certain time delay. 
Thus, a chip delay's time duration is directly related to 

35 the number of chips in the delay. Longer delays have 
more chips then shorter delays. It is to be appreciated 
that the use of chip delays is due to the use of a CDMA 
wireless interface (W-CDMA) between remote terminals 
and base stations in UMTS. According to this embodi- 

40 ment of the invention , those classes with a higher priority 
are given a smaller average random chip delay such that 
their access requests will have a smaller time delay and 
thus a higher probability of being captured compared to 
those submitted by users with a lower priority class. 

45 [0033] In the access priority embodiment in FIG. 5, the 
remote terminal, in step 501 , receives and stores (in its 
memory) the following access priority system parame- 
ters broadcast by the base station: M which is Ihe 
number of logical access channels which exist between 

so the remote terminal and the base station; Kj which is the 
maximum number of retransmission attempts for each 
class i; a random chip delay for each class i distributed 
between (RN i( ... , RN/), where RN, < RN j+1 , RN/ < 
RN j+1 \ e.g., RN 0 < RN V RN 0 ' < RN/. It is to be appre- 

55 ciated that i = 0, 1 etc. Thus, the chip delay associated 

with access priority class 0 (highest priority) is selected 
from a distribution of random chip delays that on aver- 
age are smaller than the chip delays in the distribution 
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associated with a lower access priority class, e.g., class 
1. Thus, a remote terminal set as class 0 has a higher 
priority than a remote terminal set at class 1 . 
[0034] Accordingly, in step 502, the remote terminal 
(via the processor associated therewith) determines 
whether a new access request is required due to receipt 
of packets to be transmitted. If so, in step 504, the re- 
mote terminal selects a logical access channel (1, .... 
M). Then, based on the required priority class (e.g., due 
to nature or content of the data to be transmitted) or pri- 
ority class attributed to the remote terminal (e.g., if the 
user of the remote terminal has subscribed to a partic- 
ular, level. otservice, e.g., regular, premium), the remote 
terminal selects a random chip"- delay -fronrv distribution 
(RNj RNf) in step 506. So, if the priority of the trans- 
mission is high, the remote terminal selects from the 
lowest random chip delay distribution thereby increas- 
ing the likelihood of a successful request. If the priority 
of the transmission is low, the remote terminal selects 
from the highest random chip delay distribution thereby 
decreasing the likelihood of a successful request as 
compared to those remote terminals requesting access 
at a higher priority class. Of course, depending on the 
priority, the remote terminal may select from any random 
chip delay distribution in between. The access request 
is then transmitted according to the selected chip delay 
on the selected logical access channel, in step 506. 
[0035] "Next, in step 510, the terminal determines 
whether the access request was successfully received 
by the base station. This may be accomplished by the 
base station transmitting an access request acknowl- 
edge message to the terminal (step 1106 in FIG. 11). If 
the access request has been successful, then the ac- 
cess priority control method ends (block 512) and the 
remote terminal can transmit its packets according to 
the packet transfer scheme employed in the UMTS. 
[0036] However, if the request is not successful, in 
step 514, the terminal increments a variable, referred to 
as no_tx, by one (no_tx ++). It is to be understood that 
the variable no_tx represents the number of times an 
access request has been transmitted by the remote ter- 
minal (the value is stored in the memory associated with 
the remote terminal processor). In step 516, no_tx is 
compared to Kj (the maximum number of retransmission 
attempts for class i). If no_tx is greater than Kj, then the 
current access request is dropped (step 518). It is to be 
understood that highei priority classes are assigned a 
higher K ; (i.e., Kj > K j+1 ) so that more retransmission at- 
tempts may be made. If the maximum number of re- 
transmissions has not been reached, then a backoff 
process is performed, in step 520. It is to be appreciated 
that a backoff procedure is preferably employed since, 
assuming several remote terminals unsuccessfully at- 
tempted to transmit access request signals at about the 
same time (the lack of success may be due to, for ex- 
ample, collisions between requests), it is not preferable 
for each remote terminal to attempt to re-transmit at 
around the same time Thus, each terminal delays its 



retransmission for a randomly selected amount of time 
such that the likelihood of collisions of the re-transmitted 
access requests is decreased. In an alternative embod- 
iment, backoff may be performed according to the in- 
5 ventive procedure described below with respect to FIG . 
6. After backoff, the remote terminal waits, in step 522, 
for the next available access slot and then returns to 
step 504 to repeat the process. 

[0037] Referring now to FIG. 6, a flow chart of a meth- 

10 od 600 of access priority control at a remote terminal 
according to a second embodiment of the present in- 
vention is shown. Again, it is to be appreciated that this 
methodology is performed in a remote terminal (e.g., ter- 
minal 2 or 4) whicrvhas generated or received packets 

75 io be transmitted uplink to a UMTS base station (e.g., 
base station 6). The embodiment illustrated in FIG. 6 is 
hereinafter referred to as Random Backoff Based Ac- 
cess Priority (RBBAP). Generally, in the RBBAP ap- 
proach, each priority class is advantageously assigned 

20 a different average backoff delay. Requests associated 
with higher access priority will have a smaller average 
backoff delay. Whenever there is a collision or other rea- 
son an access request is not successfully received at 
the base station, the remote terminal, depending on the 

2S class i, chooses a random delay distributed between the 

range (D % Df) with D t < D/, D, < D j+1 , D,' < D j+1 ' , 

where class i has a higher priority than class i+1 . 
[0038] In the access priority embodiment in FIG. 6, the 
remote terminal, in step 601 , receives and stores (in its 

30 memory) the following access priority system parame- 
ters broadcast by the base station: M which is the 
number of logical access channels which exist between 
the remote terminal and the base station; Kj which is the 
maximum number of retransmission attempts for each 

35 class i; a random delay distributed between the range 
(D h .... D{) with Di < Dj\ Dj< D k1 , D{ < D i+1 \ where class 
i has a higher priority than class i+1. Thus, a backoff 
delay associated with a higher access priority class is 
selected from a distribution of random backoff delays 

-to that on average are smaller than backoff delays in a dis- 
tribution associated with a lower access priority class. 
For example, a remote terminal set as class 0 has a 
higher priority than a remote terminal set at class 1 . 
[0039] Accordingly, in step 602, the remote terminal 

•*$ (via the processor associated therewith) determines 
whether a new access request is required due to receipt 
of packets to be transmitted. If so, in step 604, the re- 
mote terminal selects a logical access channel (1, ... , 
M). The access request is then transmitted on the se- 

so lected logical access channel, in step 606. Next, in step 
608, the terminal determines whether the access re- 
quest was successfully received by the base station. 
Again, this may be accomplished by the base station 
transmitting an access request acknowledge message 

55 to the terminal (step 1106 in FIG. 11). If the access re- 
quest has been successful, then the access priority con- 
trol method ends (block 610) and the remote terminal 
can transmit its packets according to the packet transfer 
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scheme employed in the UMTS. 

[0040] However, if the request is not successful, in 
step 612, the terminal increments variable no_tx by one. 
In step 614, nojx is compared to Kj. If no_tx is greater 
than Kj. then the current access request is dropped (step 
616). If the maximum number of retransmissions has not 
been reached, then a backoff process is performed, in 
step 618. In step 618, based on the required priority 
class or priority class attributed to the remote terminal, 
the remote terminal selects a random backoff delay from 
distribution (Dj D{). So, if the priority of the transmis- 
sion is high, the remote terminal selects from the lowest 
.random backoff .delay distribution thereby increasing the 
likelihood of a successful request: That* is; the backoff 
delay is relatively short such that re-transmission is rel- 
atively sooner than for lower classes. If the priority of 
the transmission is low, the remote terminal selects from 
the highest random backoff delay distribution thereby 
decreasing the likelihood of a successful request as 
compared to those remote terminals requesting access 
at a higher priority class. Of course, depending on the 
priority, the remote terminal may select from any random 
backoff delay distribution in between. After backoff; the 
remote terminal waits, in step 620, for the next available 
access slot and then returns to step 604 to repeat the 
process. 

[0O41] Referring now to FIG. 7, a flowchart of a meth- 
od 700 of access priority control at a remote terminal 
according to a third embodiment of the present invention 
is shown. Again, it is to be appreciated that this meth- 
odology is performed in a remote terminal (e.g. , terminal 
2 or 4) which has generated or received packets to be 
transmitted uplink to a UMTS base station (e.g., base 
station 6). The embodiment illustrated in FIG. 7 is here- 
inafter referred to as Variable Logical Channel-based 
Access Priority (VLCAP). Generally, in the VLCAP ap- 
proach, each subscriber is given an access priority class 
i. Those with the highest priority (class 0) can access all 
the logical access channel for which the base station is 
configured (e.g., 16x8), while those with lowest priority 
are only allowed to access a small subset of logical ac- 
cess channels, e.g., only one preamble signature with 
8 time offsets. A rationale behind this approach is that 
the larger the number of logical access channels that 
the remote terminal has to choose trom, the higher the 
likelihood of finding a channel on which the access re- 
quest will be successfully transmitted. 
[0O42] In the access priority embodiment in FIG. 7, the 
remote terminal, m step 701, receives and stores (in its 
memory) the following access priority system parame- 
ters broadcast by the base station: M which is the 
number of logical access channels which exist between 
the remote terminal and the base station; Nj which is the 
maximum number of logical access channels class i can 
access, where N ; > N j+) and N 0 = M; and Kj which is the 
maximum number of retransmission attempts for each 
class i. 

[0043] Accordingly, in step 702, the remote terminal 



(via the processor associated therewith) determines 
whether a new access request is required due to receipt 
of packets to be transmitted. If so. in step 704. the re- 
mote terminal selects a logical access channel (1 

5 Nj). That is, the logical channel is selected from a set of 
logical channels where the size of the set depends on 
the priority class of the request. If the request is in ac- 
cordance with the highest priority class, the remote sta- 
tion can choose from all M logical access channels, 

10 while decreasing priority requests have decreasing 
sized subsets from which to choose. In an alternative 
embodiment, the remote terminal can store and then se- 
lect a random chip delay at this point according to the 
RCDAP approach in FIG/ 5. The access request is then 

is transmitted on the selected logical access channel, in 
step 706. Next, in step 708, the terminal determines 
whether the access request was successfully received 
by the base station. Again, this may be accomplished 
by the base station transmitting an access request ac- 

20 knowledge message to the terminal (step 1106 in FIG. 
11 ). If the access request has been successful, then the 
access priority control method ends (block 710) and the 
remote terminal can transmit its packets according to 
the packet transfer scheme employed in the UMTS. 

25 [0044] However, if the request is not successful, in 
step 71 2 t the terminal increments variable no_tx by one. 
In step 714, no_tx is compared to K v If no_tx is greater 
than Kj, then the current access request is dropped (step 
716). If the maximum number of retransmissions has not 

30 been reached, then a backoff process is performed, in 
step 718. In an alternative embodiment, the backoff 
process is the same as described above in step 618 of 
FIG. 6. After backoff, the remote terminal waits, in step 
720, for the next available access slot and then returns 

3S to step 704 to repeat the process. 

[0045] Referring to FIG. 8. a flow chart of a method 
800 of access priority control at a remote terminal ac- 
cording to a fourth embodiment of the present invention 
is shown. It is to be understood that method 800 is a 

•to variation of the VLCAP scheme of FIG. 7. The variation 
is referred to as VLCAP' and specifically takes into ac- 
count a special UMTS access channel structure. That 
is, even though there are 8 time offsets for each pream- 
ble signature, there may not be eight parallel processing 

*s units at the base station due to a limitation on the 
processing complexity associated with the base station. 
For example, there may only be four receivers with each 
receiver programmed to capture, for example, the (i ,h . 
(i+4) th ) time offsets. However, it is to be appreciated that 

so the time offsets do not have to be in sequence. That is, 
the receiver may capture the first four time offsets re- 
ceived, e.g., time offsets 1, 3. 5, and 6. Thus, according 
to tho VLCAP' approach, those requests with lower pri- 
ority classes will be assigned a higher number for the 

ss time offsets, thus allowing the access requests from 
higher priority classes to be captured by the receivers 
first. That is, if the class is a high priority class, it has the 
low time offsets assigned thereto (eg.,1 through 4) from 
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which to select, while a class of a low priority has the 
high time offsets assigned thereto (e.g., 5 through 8) 
from which to select. Therefore, the higher priority ac- 
cess requests are more likely to be received over the 
lower priority access requests. 

[0046] In the access priority embodiment in FIG. 8, the 
remote terminal, in step 801 , receives and stores (in its 
memory) the following access priority system parame- 
ters broadcast by the base station: P which is the max- 
imum number of preamble signatures (e.g : , P < 16); T 
which is the number of time offsets (e.g., T < 6) whereby 
M is the total (PxT) number of logical access channels 
representing the number of processing units and time 
searching capability that the base station includes; and 
Kj which is the maximum number of retransmission at- 
tempts for each class i. 

[0047] Accordingly, in step 802, the remote terminal 
(via the processor associated therewith) determines 
whether a new access request is required due to receipt 
of packets lo be transmitted. IT so, in step 804, the re- 
mote terminal selects a preamble from among (1, ... , 
P). Then, in step 806, for class i, the remote terminal 

selects one time offset from (Tj T{) such that T ; < 

Tm. T|'< T kl \ T 0 = 0, T max * = 8. For example, class 0 
(highest priority class) can chooso from tho set of time 
offsets ranging between time offset 0 through time offset 
4. In an alternative embodiment, the remote terminal 
"can alscTstore and then select a random chip delay at 
this point according to the RCDAP approach in FIG. 5. 
The access request is then transmitted on the selected 
logical access channel, in step 808. 
[0048] Next, in step 810, the terminal determines 
whether the access request was successfully received 
by the base station. Again, this may be accomplished 
by the base station transmitting an access request ac- 
knowledge message to the terminal (step 1106 in FIG. 
1 1 ). If the access request has been successful, then the 
access priority control method ends (block 812) and the 
remote terminal can transmit its packets according to 
the packet transfer scheme employed in the UMTS. 
[0049] However, if the request is not successful, in 
step 814, the terminal increments variable no_tx by one. 
In step 816. no_tx is compared to Kj. If no_tx is greater 
than K h then the current access request is dropped (step 
818). If the maximum number of retransmissions has not 
been reached, then a backoff process is performed, in 
step 820. In an alternative embodiment, the backoff 
process is the same as described above in step 618 of 
FIG. 6. After backoff, the remote terminal waits, in step 
822, for the next available access slot and then returns 
to step 804 to repeat the process. 

[0050] Referring now to FIG. 9, a flow chart of a meth- 
od 900 of access priority control at a remote terminal 
according to a fifth embodiment of the present invention 
is shown. Again, it is to be appreciated that this meth- 
odology is performed in a remote terminal (e.g., terminal 
2 or 4) which has generated or received packets to be 
up-linked to a UMTS base station (e.g., base station 6). 



The embodiment illustrated in FIG. 9 is hereinafter re- 
ferred to as Probability Based Access Priority (PBAP). 
Generally, in the PBAP approach, each subscriber is 
given an access priority class i. Each access priority 

5 class i can only transmit access requests with a certain 
probability P { . Those with the highest priority (class 0) 
always transmit their access requests whenever they 
have an access request. For example, P 0 = 1 (high pri- 
ority) and Pt =0.5 (low priority). Each access priority 

;o class also has a different maximum number of re-at- 
tempts. A lower access priority class has a lower maxi- 
mum number of re-attempts. 

[0051] In the access priority embodiment in FIG. 9, the 
remote terminal, in step 901, receives and stores (in its 
is memory) the following access priority system parame- 
ters broadcast by the base station: M which is the 
number of logical access channels which exist between 
the remote terminal and the base station: probability P- t 
for each class i; and Kj which is the maximum number 
20 of transmission attempts associated with class I, where 
Pi = 1 and P; < P M : K 0 = K max and K M < Kj. 
[0052] Accordingly, in step 902, the remote terminal 
(via the processor associated therewith) determines 
whether a new access request is required due to receipt 
25 of packets to be transmitted. If so, in stop 904, tho re- 
mote terminal sets variable no_tx = 0. This is the retrans- 
mission attempts variable. Then, in step 906, the remote 
terminal determines if x> (1 - P f ). It is to be appreciated 
that x is afrandom variable uniformly distributed between 
30 0 and 1: If x is not greater than (1 - Pj). the remote ter- 
minal waits, in step 908, for the next available access 
slot and then returns to step 904 to repeat the process. 
If x> (1 - Pj), the remote terminal selects a logical access 
channel (1, ... , M). The access request is then transmit- 
35 ted on the selected logical access channel, in step 9 1 2. 
Next, in step 914, the terminal determines whether the 
access request was successfully received by the base 
station. Again, this may be accomplished by the base 
station transmitting an access request acknowledge 
40 message to the terminal (step 1106 in FIG. 11). If the 
access request has been successful, then the access 
priority control method ends (block 916) and the remote 
terminal can transmit its packets according to the packet 
transfer scheme employed in the UMTS. 
45 [0053] However, if the request is not successful, in 
step 91 8, the terminal increments variable no_tx by one. 
In step 920, no_tx is compared to Kj. If no_tx is greater 
than Kj, then the current access request is dropped (step 
922). If the maximum number of retransmissions has not 
so been reached, then a backoff process is performed, in 
step 924. In an alternative embodiment, the backoff 
process is the same as described above in step 618 of 
FIG. 6. After backoff, the remote terminal waits, in step 
908, for the next available access slot and then returns 
S5 to step 904 to repeat the process. 

[0054] Referring now to FIG. 10, a flow chart of a 
method 1000 of access priority control at a remote ter- 
minal according to a sixth embodiment of the present 
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invention is shown. It is to be appreciated that this meth- 
odology is performed in a remote terminal (e.g. , terminal 
2 or 4) which has generated or received packets to be 
up-linked to a UMTS base station (e.g.. base station 6). 
The embodiment illustrated in FIG. 10 is hereinafter re- 
ferred to as Retransmission Based Access Priority (RE- 
BAP). Generally, in the REBAP approach, it is assumed 
that all access requests have an access packet priority 
(APP) associated therewith. The REBAP scheme gives 
retransmitted access requests a higher priority over new 
access requests. Such a feature is attractive for certain 
applications which require a smaller 95 th or 99 th percen: 
tile access-delay for all successful, attempts rather than 
a smaller -average access* delay: All ' new ^access re- 
quests are given the lowest APP class (n max - 1). Then, 
their priorities are dynamically adjusted based on the 
number of retransmissions. The access packets can ac- 
cess all the M logical access channels but depending 
on the access packet priority class, they will choose a 
different random chip delay. The lowest APP class has 
the highest average random chip delay distribution from 
which to select. Those access requests that fail and 
need to be retransmitted preferably have their APP 
class adjusted. Note that an access service priority 
(ASP) class may also be defined in addition to the APP 
feature. Those requests with highest ASP, say class 0, 
will automatically increase their failed access requests' 
APP with each reattempt. Those with lower ASPs adjust 
the APP of their failed attempts less aggressively. For 
example, ASP class 1 may increase the APP of an ac- 
cess request only after it fails twice. 
[0055] In the access priority embodiment in FIG. 10, 
the remote terminal, in step 1001, receives and stores 
(in its memory) the following access priority system pa- 
rameters broadcast by the base station: M which is the 
number of logical access channels wh ich exist between 
the remote terminal and the base station; APP which, 
for each class i, has . two numbers associated there- 
with, namely, Kj which is the maximum number of re- 
transmission attempts for each class i and RNj which 
represents the random chip delay for each class i. Also, 
it is assumed that APP ranges from 0, .. , n max -1 , where 
0 has a higher priority. If ASP is used, then parameters 
ASP and Sj are also transmitted by the base station and 
received and stored by tht; remote terminal. Sj repre- 
sents the number of retransmissions required for class 
j before the APP of the access requests, from that class 
j, will be updated. Thus, while Kj relates to the APP pri- 
ority class and Sj relates to the ASP priority class. For 
example, for ASP = 0, 1 , 2; S 0 = 1, = 3, S 2 = 5. 
[0056] Accordingly, in step 1002, the remote terminal 
(via the processor associated therewith) determines 
whether a new access request is required due to receipt 
of packets to be transmitted. If so, in step 1004, the re- 
mote terminal sets APP = n max -1. ASP = j, no_tx - 0, 
and adj - 0 (adj is explained below). Then, in step 1006, 
the remote terminal selects a random chip delay from 
distribution (RNj, .. , RNj') In step 1008, the remote ter- 



minal selects a bgical access channel (1 M). The 

access request is then transmitted on the selected log- 
ical access channel according to the chip delay, in step 
1010. Next, in step 1012, the terminal determines 

5 whether the access request was successfully received 
by the base station. This may be accomplished by the 
base station transmitting an access request acknowl- 
edge message to the terminal (step 1106 in FIG. 11). If 
the access request has been successful, then the ac- 

10 cess priority control method ends (block 1014) and the 
remote terminal can transmit its packets according to 
the packet transfer scheme employed in the UMTS. 
[0057] However, if the request is not successful, in 
step 1 01 6, the terminal increments variables no_tx and 

75 adj by one. The variable no_tx represents the number 
of times an access request has been transmitted by the 
remote terminal and adj represents the variable used to 
check whether Sj has been reached. Instep 1018, no_tx 
is compared to Kj. If no_tx is greater than or equal to K jt 

20 then the current access request is dropped (block 1 020) . 
However, if no_tx is not greater than or equal to Kj, then 
the remote terminal determines whether adj is greater 
than or equal to Sj (step 1022). If no, APP remains the 
same as set in step 1004. Then, a backoff process is 

25 performed, in step . 1024. The backoff process may be 
the same as described in step 618 in FIG. 6. After back- 
off, the remote terminal waits, in step 1026, for the next 
available access slot and then returns to step 1006 to 
repeat the process. However, if adj is greater than or 

30 equal to Sj. then APP is decreased by one (APP = n-1 ) 
thereby increasing the priority of the re-transmitted re- 
quest (step 1 028). Also adj is reset to zero in step 1 023. 
Then, the backoff process is performed, in step 1024. 
After backoff, the remote terminal waits, in step 1026. 

35 for the next available access slot and then returns to 
step 1006 to repeat the process. 
[0058] It is to be appreciated that use of the access 
priority methodologies of the invention, as described 
herein, may be useful and advantageous in a variety of 

•*o applications. The following are merely a few examples 
of such applications. In existing wireless access sys- 
tems, no provision has been provided to allow users that 
have an urgent need to gain access at a higher priority 
than other types ol users. One possible implementa- 

•*5 tions ot access priority according to the invention is to 
reserve some logical access channels such that only 
emergency users can access. In another scenario, a 
service provider can differentiate, according to the 
present invention, between different types of customers 

so based on the service charges that they pay. A CEO may 
desire to have a smaller access delay so that his mes- 
sages can get across the network faster than others. 
Preferably, this service is coupled with service priority 
to ensure that users can perceive a better end-to-end 

55 delay. Also, in order to give smaller access delay to 
some real time services, e.g. , interactive video, one may 
again use the access priority features of the invention 
to achieve this purpose. In addition, the present inven- 
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tion provides new access features to be included in 
UMTS MAC. Access priority can be used together with 
scheduling algorithms to provide different Quality of 
Service to customers either based on service charge, 
emergency needs or delay requirements. 5 
[0059] Although illustrative embodiments of the 
present invention have been described herein with ref- 
erence to the accompanying drawings, it is to be under- 
stood that the invention is not limited to those precise 
embodiments, and that various other changes and mod- io 
ifications may be affected therein by one skilled in the 
art without departing from the scope and spirit of the in- 
.ventioa.For example, although certain variations of the 
embodiments- illustrated in the flow charts were de- 
scribed above, it is to be appreciated that the present 
invention contemplates combining any embodiment, or 
variation thereof, with one or more other embodiments, 
or variations thereof. 

ODMAFO MAC Protocol Operation 20 

[0060] The overall ODMAFQ MAC protocol operation 
is illustrated in the flowcharts of FIGs. 12A and 12B. As 
seen from a remote host (terminal), FIG. 12A, after es- 
tablishment of the power level for uplink transmission 2S 
1210, the remote hosts participate in uplink initial con- 
tention 1215 during which each remote with packets to 
" send requests access to the AP {base station). If some 
of these access requests collide 1 220, in that they are 
submitted in the same reservation minislot, the colliding 30 
remote hosts participate in uplink conflict resolution 
1225. Otherwise, the AP proceeds to allocate uplink 
bandwidth 1 230 among the remote hosts requesting ac- 
cess, followed by allocation of bandwidth for its own 
downlink transmission 1235. Each remote host waits to 35 
receive a transmit permit 1237 during a subsequent 
downlink transmission and, upon receiving one, trans- 
mits a waiting packet from its queue. If the queue at a 
remote is not then empty 1238, the remote returns to 
waiting for additional transmit permits 1237, otherwise 
it waits for new packets to arrive 1239. 
[0061] As illustrated in FIG. 12B, the AP monitors ac- 
tivity in the received contention reservation slots 1260. 
When it receives a successful access request 1 265 : the 
AP sends reservation acknowledgments (ACKs) 1270 
and adds the newly successful remotes to the sched- 
uled list 1 275. Whether or not there riave been new suc- 
cessful access requests 1 265, the AP also monitors the 
uplink dataslots 1 280 as long as the scheduled list is not 
empty, and when it receives a successfully transmitted 
packet 1285, it replies with a data ACK 1290. The AP 
then schedules its downlink packets 1240, schedules 
the uplink transmissions 1245 of the successfully con- 
tending remote hosts, issues the associated transmit 
permits 1 250, and then transmits downlink data packets 
1255. after which it . returns to monitoring activity in the 
contention reservation slots 1260 

[0062] It may be desirable to allow for an optional 



channel holding feature whereby each queue can re- 
main empty for a short while without the Access Point 
releasing the bandwidth reservation. This allows high 
priority users to remain in the base station=s reserved 
bandwidth list for an allotted amount of time before it-is 
released, encouraging low latency of real-time packets 
(i.e. little or no delay for packets of time-sensitive data 
such as voice communications) by avoiding all the setup 
signaling messaging required for channel reservation. 
Utilizing this feature, when a queue is empty, a timer is 
triggered at the wireless modem. As long as new pack- 
ets arrive at the wireless modem before this timer ex- 
pires, the wireless modem does not need to make a new 
access request/ At the AP, if this feature- is turned on, 
then the AP will still allocate a transmit permit for one 
data slot to this particular wireless modem every alter- 
nate uplink frame, even if the last uplink data transmis- 
sion from the wireless modem has indicated that the 
queue is empty. The AP will also start a timer. When the 
timer expires and the AP has not received new packets 
from that wireless modem, then the AP will remove the 
wireless modem from the reserved bandwidth list. This 
channel holding feature is particularly useful if the band- 
width reservation process takes a while to complete, al- 
lowing low latency for real-time packets that, while not 
arriving back-to-back, are not so far apart as to warrant 
a separate bandwidth reservation request via conten- 
tion for each data packet. However, for bursty sources 
that do not need this channel holding feature, when a 
packet arrives to find an empty buffer, the modem will 
still send an access request to the AP via one of the 
contention minislots. 

[0063] FIG. 13A illustrates is an embodiment of a 
method for access control. N contention reservation 
minislots are configured in each uplink frame 1310. The 
N minislots are organized into a plurality of access pri- 
ority classes, each class having a different priority. The 
AP is configured to allow m access priority classes 1 31 5. 
Each remote host of access priority class i, randomly 
picks 1 320 one contention minislot and transmits an ac- 
cess request, the contention minislot picked being in a 
range from 1 to Nj where N (i+1) < Nj and N , =N. The base 
station receives 1 325 the access requests and sequen- 
tially examines the received contention minislots. If the 
minislot currently being examined contains an uncollid- 
ed request 1330, the AP grants access 1835 to the re- 
mote host corresponding to the uncollided access re- 
quest. If the minislot currently being examined contains 
a collided request 1330, the AP will not send an ACK, 
causing the affected remote nodes to perform conflict 
resolution 1340. After the conflict resolution period, the 
AP grants access to the Awinning= remote host 1345. 
Meanwhile, if more minislots remain to be examined 
1350, the AP continues to check minislots for collisions 
1330, either granting access to successful requesting 
hosts 1 335 or awaiting the outcome of conflict resolution 
1340. 

[0064] FIG. 1 3B is a flowchart illustrating an alternate 
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embodiment of a method for access control. The N min- 
islots are organized into a plurality of access priority 
classes, each with a different priority. N contention res- 
ervation minislots are configured in each uplink frame 
1310. The N minislots are organized into a plurality of 
access priority classes, each class having a different pri- 
ority. The AP is configured to allow m access priority 
classes 1 31 5. Each remote host of access priority class 
i and with a stack level that equals 0, then transmits an 
access request with a probability Pj where P (j+1) < Pjand 
P 1= =1 1360. The base station receives 1325 the access 
requests and sequentially examines the received con- 
tention .minislots. If .the minislot currently being exam- 
■ ined contains an uncol lided request 1 330;- the AP grants 
access 1335 to the remote host corresponding to the 
uncollided access request. If the minislot currently being 
examined contains a collided request 1330, the AP will 
not send an ACK, causing the affected remote nodes to 
perform conflict resolution 1340. After the conflict reso- 
lution period, the AP grants access to the Awinning= re- 
mote host 1345. If more minislots remain to be exam- 
ined 1350, the AP continues to check minislots for col- 
lisions 1330, either granting access to successful re- 
questing hosts 1 335 or awaiting the outcome of conflict 
resolution 1340. 

[0065] IDLE, SUCCESS and COLLISION status infor- 
mation is conveyed back to the wireless modems. The 
AP places the slot status information in the downlink res- 
ervation acknowledgment field. There are three alterna- 
tive preferred conflict resolution methods . that may be 
used. The first method is suggested in the IEEE 802. 1 4 
standard, and is described along with two new methods 
below. Simulation results show that the second method 
described provides a better access delay. 
[0066] In the first conflict resolution method, suggest- 
ed in IEEE standard 802.14, each wireless node that 
wishes to transmit randomly picks one of the reservation 
minislots. if a collision is indicated, a modem that was 
affected by the collision retransmits based on a random 
binary-exponential back-off method. This backoff meth- 
od operates in accordance with the following: 

1. The modem generates a random number, I, uni- 
formly distributed between 0 and 2) - 1 , where j is 
the number of collisions th«i the modem experi- 
enced for the packet it is attempting to transmit. If j 
is larger than 10, then I is selected from a uniform 
distribution between 0 and 2 10 - 1 . 

2. The modem skips the next 1-1 contention slot op- 
portunities of the same kind (either minislot or data 
contention slot), and then retransmits its previously 
collided packet in the next immediate contention 
slot opportunity. 

[0067] The operation of this method is depicted in 
FIG. 14A. A wireless node waiting to access the AP ran- 
domly picks 1402 a reservation minislot in which to 



transmit an access request. If the node is affected by a 
collision 1404 ( the node generates 1403 the random 
number I and skips 1410 the next 1-1 contention slot op- 
portunities of the same kind. The node than retransmits 
5 1412 the access request for the collided packet at the 
next immediate contention slot opportunity. If the node 
is not affected by a collision 1404, then if the queue at 
the node is empty 1405, the node transmits 1406 the 
packet and returns to the waiting state 1 402. If the queue 
at the node is not empty 1405, then, after receiving a 
transmit permit from the AP, the node transmits 1407 
the current packet along with a piggybacked reservation 
request for transmission of the next packet in its queue, 
continuing to transmit packets with piggybacked reser- 
vation requests 1407 after receiving transmit permits 
until the queue is empty 1405 and the final packet has 
been transmitted 1406, after which the node returns to 
the waiting state 1402. 

[0068] In the second and third methods, the AP broad- 
casts the outcome of each contention in the reservation 
minislots to all wireless nodes via a downlink broadcast 
message. In the second method, the modem in each 
wireless node is characterized by a stack level, and only 
wireless nodes with a stack level equal to zero are per- 
mitted to transmit access request packets. Modems with 
a stack level greater than zero are regarded as back- 
logged. For example, when there are M reservation min- 
islots, each remote node at stack level 0 can randomly 
pick one of the M minislots. At the end of a timeslot, wire- 
less node i changes stack level based on the outcome 
of a transmission in that time slot. This method allows 
newly active wireless nodes to join in with those existing 
wireless nodes havipg stack level 0 during a particular 
conflict resolution period. Each wireless node in a re- 
quest state increments its stack level by one if it does 
not transmit an access request packet and receive a 
negative acknowledgment (e.g., that there was a colli- 
sion) from the base station (AP). On the other hand, a 
wireless node decrements its stack level by one if it re- 
ceives a positive acknowledgment from the base sta- 
tion, indicating successful transmission of an access re- 
quest. Each wireless node that participates in the ac- 
cess request transmission randomly Aflips a coin= to de- 
termine whether its stack level stays at level 0 or is in- 
cremented by one upon receiving a negative acknowl- 
edgment from the base station. 
[0069] The rules of the second method are: 

1 . When a wireless node first wishes to gain access 
to the network or has gained access and wishes to 
send new data, it is placed in a request state and 
assigned a stack level of zero. 

2. When there are M reservation minislots, each 
wireless node in a request state randomly picks one 
of the M reservation minislots to be its assigned 
minislot in which to transmit an access request 
packet. 
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3. When the wireless node is characterized by a 
stack level equal to zero, it transmits an access re- 
quest packet; however, when the remote node is 
characterized by a stack level other than zero, it 
does not transmit an access request packet. s 

4. At the end of the time slot, each wireless node 
changes its stack level based on the outcome (ei- 
ther COLLIDED, IDLE or SUCCESS) of an access 
request, as reported for its assigned minislot in the io 
reservation acknowledgment field of a downlink 
message from the access point. 

... -^A. A wireless node that sent ah access request 

and received a SUCCESS outcome will be re- is 
moved from the request state. 

B. A wireless node that sent an access request 
and received a COLLIDED outcome will either 
increment its slack level by one or leave its 20 
stack level at zero depending upon the out- 
come of a random draw. 

C. A wireless node that is in the request state 
and did not send an access request (i.e. , a node 2s 
backlogged with stack level > 0) will increment 

its stack level by one if the outcome reported in 
the reservation acknowledgment field for the 
assigned minislot is COLLIDED. 

30 

D. A wireless node that is in the request state 
and that did not send an access request (i.e., a 
node backlogged with stack level > 0) will dec- 
rement its stack level by one if the outcome re- 
ported in the reservation acknowledgment field 35 
for the assigned minislot is SUCCESS. 



[0070] The operation of this method is depicted in 
FIG. 14B. A wireless node waiting to access the AP or 
send new data 1432 sets its stack level to 0 and enters 40 
the request state. If the stack level of the node is 0 1 434, 
the node randomly picks 1436 a reservation minislot for 
transmission of an access request and transmits the ac- 
cess request. If the outcome of. the request is SUCCESS 
1438, and the queue at the node is empty 1439, the •*$ 
node transmits 1440 the current packet and exits the 
request state, returning to the waiting sidte 1432. If the 
queue at the node is not empty 1 439, then, after receiv- 
ing a transmit permit from the AP, the node transmits 
1441 the current packet along with a piggybacked res- so 
ervation request for transmission of the next packet in 
its queue, continuing to transmit packets with piggy- 
backed reservation requests 1441 after receiving trans- 
mit permits until the queue is empty 1 439, at which point 
it transmits the remaining packet 1 440, exits the request ss 
state, and returns to the waiting state 1402. 
[0071] If the outcome of the reservation request 1436 
was not SUCCESS 1433, the node participates in a ran- 



dom draw 1444 to learn whether to increment 1448 its 
stack level by 1 or leave 1446 its stack level at 0. If the 
stack level remains 1446 at 0, the nods again randomly 
picks 1436 a reservation minislot for transmission of an 
access request and transmits the access request. If the 
stack level is incremented 1448, the stack level will not 
be 0 1434. If the stack level of any remote node is not 
0 1434 then if the outcome of the previous reservation 
request was COLLIDED 1450 : the node increments 
1452 its stack level by 1 . If the outcome for the previous 
reservation request was not COLLIDED 1450, the node 
decrements 1454 its stack level by 1 . 
[0072] The third conflict resolution method is a modi- 
fication of the second: In the third conflict resolution 
method, the modem in each wireless node is again char- 
acterized by a stack level, and only wireless nodes with 
a stack level equal to zero are permitted to transmit ac- 
cess request packets. Modems with stack level greater 
than zero are regarded as backlogged. The rules of the 
third method are: 

1 . When a wireless node first wishes to gain access 
to the network or has gained access and wishes to 
send new data, it is placed in a request state and 
assigned a stack level of zero. 

2. When there are M reservation minislots, each 
wireless node in a request state randomly picks one 
of the M reservation minisffots to be its assigned 
minislot in which to transmit an access request 
packet. 

3. When the wireless node is characterized by a 
stack level equal to zero, it transmits an access re- 
quest packet; however, when the remote node is 
characterized by a stack level other than zero, it 
does not transmit an access request packet. 

4. At the end of the time slot, each wireless node 
changes its stack level based on the outcome (ei- 
ther COLLIDED, IDLE or SUCCESS) of all access 
requests as reported in the reservation acknowl- 
edgment fields of a downlink message from the Ac- 
cess Point. 

A. A wireless node that sent an access request 
and received a SUCCESS outcome will be re- 
moved from the request stale. 

B. A wireless node that sent an access request 
and received a COLLIDED outcome will either 
increment its stack level by one or leave its 
stack level at zero depending on the outcome 
of a random draw. 

C. A wireless node that is in the request state 
and that did not send an access request (i e. , a 
node backlogged with stack level > 0) will dec- 
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rement its stack level by one if the outcomes of 
all access requests reported in at least 80% (or 
some other predefined threshold) of the reser- 
vation acknowledgment fields is either SUC- 
CESS or IDLE. Otherwise, the remote node will 
increment its stack level by one. 

D. When the backlogged modem=s stack level 
is decremented to zero, the modem randomly 
picks one of the M minislots (or the I; minislots 
if access priority is implemented) to resend its 
request. 

[0073] rt 4 The operation of this -method is depicted in 
FIG. 14C and is similar to that of the method of Fig. 1 4B. 
A wireless node watting to access the AP or send new 
data 1 432 sets its stack level to 0 and enters the request 
state. If the stack level of the node is 0 1434, the node 
randomly picks 1 436 a reservation minislot for transmis- 
sion of an access request and transmits the access re- 
quest. If the outcome of the request is SUCCESS 1438, 
and the queue at the node is empty 1439, the node 
transmits 1440 the current packet and exits the request 
state, returning to the waiting state 1432. If the queue 
at the node is not empty 1439, then, after receiving a 
transmit permit from the AP, the node transmits 1441 
the current packet along with a piggybacked reservation 
request for transmission of the next packet in its queue, 
continuing to transmit packets with piggybacked reser- 
vation requests 1441 after receiving transmit permits 
until the queue is empty 1439 and it has transmitted the 
remaining packet 1440 : after which it exits the request 
state, and returns to the waiting state 1402. 
[0074] If the outcome of the reservation request 1436 
was not SUCCESS 1438, the node participates in a ran- 
dom draw 1444 to learn whether to increment 1484 its 
stack level by 1 or leave 1446 its stack level at 0. If the 
stack level remains 1446 at 0, the node again randomly 
picks 1436 a reservation minislot for transmission of an 
access request and transmits the access request. If the 
stack level is incremented 1448, the stack levetwill not 
be 0 1434. If the stack level of any remote node is not 
0 1434, then if the outcome of all the reservation re- 
quests during the previous cycle was COLLIDED 1460 
for greater than or equal to some THRESHOLD percent- 
age, the node increments 1462 its stack level by 1 . If the 
outcome for the previous reservation request was not 
COLLIDED 1460, the node decrements 1464 its stack 
level by 1 . 



Claims 

1. A m€tthod of access priority control in a remote ter- 
minal of a wireless communications system, the 
method comprising the steps of: 

assigning an access priority attribute to a first 



access request signal for transmission to a 
base station in the wireless communications 
system, the access priority attribute being as- 
signed from among a plurality of access priority 
5 attributes respectively associated with pre-e"s- 

tablished access priority classes; and 

assigning an access priority attribute having a 
higher priority than a priority associated with 
10 the access priority attribute assigned to the first 

access request signal to a subsequent access 
request signal, if at least the first access re- 
quest signal is not received by the base station. 

75 2. The method of Claim 1 , wherein the access priority 
attributes include respective chip delays, the chip 
delays being respectively associated with the pre- 
established access priority classes. 

20 3. The method of Claim 2, wherein the chip delay as- 
sociated with the subsequent access request signal 
is lower than the chip delay associated with the first 
access request signal. 

25 4. The method of Claim 1 , wherein the access priority 
attributes include respective maximum allowable 
transmission attempt values, the values being re- 
spectively associated with the pre-established ac- 
cess priority classes. 

30 

5. The method of Claim 4, wherein the maximum al- 
lowable transmission attempt value associated with 
the subsequent access request signal is higherthan 
the maximum allowable transmission attempt value 

35 associated with the first access request signal. 

6. The method of Claim 1 , further comprising the step 
of monitoring for receipt of an acknowledgement 
signal from the base station indicating receipt of the 

40 first access request signal. 

7. The method of Claim 6, further including the step of 
incrementing a variable indicative of a number of 
access request transmission attempts made to the 

45 base station when the monitoring step indicates that 
a preceding access request has not been received 
by the base station. 

8. The method of Claim 7, further including the step of 
so comparing the access request transmission at- 
tempt variable to the maximum allowable transmis- 
sion attempt value to determine if the maximum al- 
lowable transmission attempts for the access prior- 
ity class have been made. 

55 

9. The method of Claim 8, further comprising the step 
of performing a backoff process when the access 
request transmission attempt variable is not at least 
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equal to the maximum allowable transmission at- 
tempt value. 



1 0. The method of Claim 1 , wherein the pre-established 
access priority classes relate to one of service level, 5 
message content, and delay requirements. 

11. The method of Claim 1, further comprising the step 
of receiving the plurality of access priority attributes 
from the base station. 10 

12. The method of Claim 1 , wherein the wireless com- 
munications system is a UMTS. 

1 3. The method of Claim 1 , wherein access request sig- 
nals are transmitted on a RACH. 

14. A method of access priority control in a base station 
of a wireless communications system, the method 
comprising the steps of: 20 

broadcasting a plurality of access priority at- 
tributes respectively associated with pre-estab- 
lished access priority classes; and 
transmitting an acknowledgement signal to a 25 
remote terminal in the wireless communica- 
tions system from which an access request sig- 
nal has been received. 



15. Apparatus for access priority control in a wireless 30 
communications system, comprising a remote ter- 
minal configured tor carrying out a method as 
claimed in any of claims 1 to 13. 

1 6. The apparatus of claim 1 5, wherein the remote ter- 35 
minal is a mobile terminal. 



17. The apparatus of claim 1 5, wherein the remote ter- 
minal is a fixed terminal. 

40 

18. Apparatus for access priority control in a wireless 
communications system, comprising: 

a base station configured for broadcasting a 
plurality of access priority attributes respectively as- 
sociated with pre-established access priority class- -*s 
es and for transmitting an acknowledgement signal 
to a remote terminal in the wireless con in judications 
system from which an access request signal has 
been received. 
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